home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Re Part Server.7 < prev    next >
Encoding:
Internet Message Format  |  1996-07-10  |  2.7 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Part Server
  2. Sent:        7/10/96 8:05 AM
  3. Received:    7/10/96 8:46 AM
  4. From:        Greg Friedman, friedman@cognosis.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. Serge Froment wrote:
  9. > >AppleEvents are the sanctioned mechanism for interprocess communication on
  10. > >the Mac.
  11. >
  12. > What about Windows? The OD parts served with this server will be ODF-based
  13. > cross-platform.
  14.  
  15. Unfortunately, OpenDoc doesn't provide a solution on Windows right now. It
  16. is unlikely that OSA will make it into the Windows implementation of
  17. OpenDoc.
  18.  
  19. > >Alternatively, it should be possible, using a shared data section and
  20. > >shared memory (probably allocated out of the system heap), to create a
  21. > >shared library that implemented interprocess communication without apple
  22. > >events. It's more work, but it might provide better performance.
  23. >
  24. > At least until Copland. AppleEvents are supposed to be used to remove
  25. > polling in MacOS 8 in order to improve performance. That's what they said
  26. > at WWDC.
  27.  
  28. I'm not suggesting an architecture that uses polling. I'm suggesting the
  29. following:
  30.  
  31. - Create a shared library that has a callable C or SOM API
  32. - Make the shared libraries data fragment shared. Use globals to point at
  33. data structures that all parts and processes should share.
  34. - Clients call the C or SOM API
  35. - Optionally use the threads manager from within the shared library
  36.  
  37. > Suppose I go with a background task that communicates with AppleEvents.
  38. > What technology do you suggest I use to implement it on the Mac: MacApp,
  39. > PowerPlant or my own stuff? Of course, if I use either MacApp or
  40. > PowerPlant, this means I write framework-independent code as much as
  41. > possible and nest it into on a Windows-based framework for the Window
  42. > version.
  43.  
  44. MacApp has been used to create background tasks, but there is no intrinsic
  45. support in the framework. I don't know about PowerPlant. I'm not sure you'd
  46. need an framework, anyhow. You probably don't want to create a fullblown
  47. app. You certainly don't need all of the menu, view, document stuff that
  48. the frameworks provide. You could probably roll your own with only a
  49. minimum of application code.
  50.  
  51. > Suppose I go with a shared library, I have another problem: I use
  52. > NeoAccess, which has its own memory management. Do you think I will have a
  53. > hard time make such stuff work inside a shared library? In particular, if
  54. > something ever does a NewHandle or calls system code that does a NewHandle,
  55. > where such a handle will be allocated?
  56.  
  57. I haven't actually used NeoAccess, but I'm pretty sure it offers some
  58. flexibility in controlling memory allocations.
  59.  
  60. Greg.
  61.  
  62.  
  63. _________________________________________________________
  64. Greg Friedman      ODF Engineering       Apple Computer
  65.  
  66.  
  67.